Fix: Handle UnicodeDecodeError and suppress exceptions for Motive 3 compatibility#5
Conversation
28167d9 to
339a31e
Compare
|
Looks good to me. Thanks for fixing these issues! |
There was a problem hiding this comment.
Pull request overview
Compatibility patch to keep the natnet Python client running against newer Motive 3.x / NatNet 4.2 servers by avoiding crashes during packet parsing, especially for MODELDEF parsing failures.
Changes:
- Decode NatNet strings with UTF-8
errors="replace"to avoidUnicodeDecodeErrorcrashes. - Suppress exceptions during packet processing so the client thread continues running even when parsing fails.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
natnet/packet_buffer.py |
Makes string decoding tolerant of invalid UTF-8 bytes. |
natnet/nat_net_client.py |
Wraps message processing in a try/except to prevent receiver loop termination on parse errors. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@hello-bharadwaj, maybe Copilot has a fair point here; we could be a bit more specific about which errors we are catching. Which exception are you getting when a MODELDEF package is being processed? Or maybe we should just implement parsing of the new MODELDEF packages. |
|
Actually, let me try to vibe-code support for 4.2 right now. I suspect that the Unicode error is also because we are parsing the modeldef wrong. |
|
@TimSchneider42 Copilot definitely had a fair point. I didnt do a lot of digging and patched it right away with the easiest answer i could think of. The actual issue was the rigid body description has quat added to it in Natnet 4.2. Thanks for catching that and fixing it. This whole conversation has been fruitful for sure. |
NatNet 0.2.0 Compatibility Patch for Motive 3.X (NatNet 4.2)
Problem Description
The
natnetpython library (v0.2.0) crashes when connecting to newer Motive servers (e.g., Motive 3.3.0 which uses NatNet Protocol 4.2).The crashes occur in two places:
MODELDEFpackets usingPacketBuffer.read_string. The newer protocol seems to send bytes that are not strictly valid utf-8 in the expected context or the parsing offset is misaligned.DataDescriptions. Because the library does not support Protocol 4.X, it fails to account for new fields or size changes in the packet structure, leading to invalid pointer offsets.Proposed Fix
PacketBuffer.read_stringto useerrors="replace"when decoding utf-8. This prevents the immediate crash on invalid strings.NatNetClient.__process_messageto catch and log exceptions instead of letting them propagate and kill the client thread.MODELDEFpacket parsing is fundamentally incompatible, we simply want to ignore it (or partial failures) so that the client can continue to processFRAMEOFDATApackets, which are backward compatible enough to extract rigid body poses.